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BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention may be directed generally to a system and method 
for processing transactions and, more particularly, to a value exchange processing 
20 system and method. 



Description of the Background 

Prompt, accurate, and efficient processing of payments may be critical to 
the success of modem consumer transactions. Sellers, such as merchants, 
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commonly employ known systems and methods to facilitate electronic payments 
via credit card and debit card, for example, and also employ known systems and 
methods for payment using cash, check, and other financial instruments. 

Promotional systems are a frequent avenue for sellers of products and 
5 services to garner new and repeat business. Historically, such systems have 
been implemented using paper coupons, mail in refunds, and rewards for repeat 
customers. These coupons, refunds, or rewards, and the overwhelming number 
of records, data, and correspondence that correspond thereto, are generally 
handled by the same entity that sells the products, thus necessitating additional 
10 man-power and expense for the seller. This additional man-power and expense 
may be spent outside of the selling process, and thus outside of the core goals of 
the seller. 

Furthermore, the customer who receives the benefits of such promotions is, 
in the prior art, inconvenienced in order to actually come into possession of the 

15 promotional benefit. Generally, the customer has to physically go to the seller's 
location, or spend time and money to send items, such as a registration card, to 
the seller to obtain the corresponding benefits. Even in cases where the benefits 
may be possessed via telephone, the customer frequently has to deal with being 
placed repeatedly on hold, or transferred between numerous divisions of the 

20 seller, because the promotion may be outside the core business of the seller, and, 
as such, may be normally a secondary consideration of the seller. 
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Therefore, the need exists for a promotional system and method that 
eliminates the need for inconvenience and expense on the part of a consumer to 
gain the promoted benefit, while also limiting the time and expense spent on the 
part of the seller outside of the seller's core business. 
5 Gift certificates are regularly used either in addition to, or in place of, 

physical gifts. The use of a gift certificate may be help consumers avoid the 
difficulties of additional shopping for gifts, such as for a birthday, holiday, or 
anniversary. Gift certificate systems have generally been implemented using 
paper coupons, which coupons may be easily forged or counterfeited, thereby 
10 leading to loss on the part of the retailer. These coupons often require, for large 
retail issuers of gift certificates, an overwhelming number of records, data, and 
correspondence that correspond to the gift certificate issuance and redemption 
process. Even the keeping of such complex records often fails to prevent 
counterfeiting. 

15 Gift certificate issuance and redemption are generally handled by the same 

entity that sells the products for which the certificate coupons may be redeemed, 
thus necessitating additional man-power and expense for the seller. This 
additional man-power and expense may be spent outside of the selling process, 
and thus outside of the core goals of the seller. 

2 o Therefore, the need exists for a gift certificate system and method that 

eliminates the use of coupons that may be easily counterfeited, which 
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counterfeiting cannot be tracked, while also limiting the time and expense spent 
on the part of the seller outside of the seller's core business. 

With the increasing use of computers by consumers, new forms of non- 
5 cash value are available to sellers as promotional tools. For example, many 

sellers provide reward points, as well as coupons and certificates, in connection 
with the seller's internet web site. Unfortunately, the accumulation, aggregation, 
tracking, and redemption of such value by consumers remains cumbersome. 
Many sellers still require the consumer to print the coupon or certificate and mail it 

10 or redeem it at the merchant's retail location. Still other sellers, such as airlines 
and credit card issuers, provide loyalty points which may be exchanged by the 
individual consumer, but which are non-negotiable and non-transferable with 
respect to other sellers and consumers. For example, an airline may offer 
frequent flyer miles as a promotional value product, and may credit the individual 

15 consumer's individual airline mileage account. However, the credit cannot be 

applied to goods or services offered by other sellers, and cannot be transferred to 
other consumers. 

Therefore, to simplify use of promotional value, there exists the need for an 
automated system and method for accumulation, aggregation, tracking, 
2 0 redemption, and exchange of non-cash value products. Additionally, there exists 
the need to aggregate all value available to an individual consumer from various 
sellers, whether cash or non-cash in nature, to allow the consumer to select any 
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and all possible combinations of accumulated value to facilitate a particular 
transaction. 

SUMMARY OF THE INVENTION 

5 A remote station for tracking promotion of at least one group of products 

each of which bears a code that uniquely identifies each product in the group, 
wherein the remote station may be communicatively coupled to at least one user 
station is disclosed. The station includes a database resident at the remote 
station, wherein the database stores ones of the uniquely identifying codes that 

10 have been previously received from one or more user stations; a database server, 
coupled to the database, that compares each new candidate code received from a 
given user station against the previously received codes stored in the database; 
wherein the database server credits an account of a user associated with the 
given user station with a non-zero promotional credit only if such new candidate 

15 code received from the given user station was not previously stored in the 

database; and wherein the database server stores such new candidate code in 
the database as a previously received code if such new candidate code was not 
previously stored in the database. 

2 o BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING 

Understanding of the present invention will be facilitated by consideration of 
the following detailed description of the preferred embodiments of the present 
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invention taken in conjunction with the accompanying drawings, in which like 
numerals refer to like parts, and wherein: 

Figure 1 illustrates the system and components comprising one embodiment of 
the present invention; 

5 Figure 2 illustrates additional hardware architecture detail for the system 
components of the embodiment shown in Figure 1 ; 

Figure 3 illustrates software architecture in accordance with one embodiment of 
the present invention; 

Figure 4A illustrates the types of value creation and redemption products available 
io to members in accordance with one embodiment of the present invention; 

Figure 4B illustrates a block diagram of a promotional system; 

Figure 4C illustrates a block diagram of a gift certificate system; 

Figure 5A illustrates product and purse relationships in accordance with one 
embodiment of the present invention; 

15 Figure 5B illustrates a flow diagram of a method for tracking promotion of at least 
one group of products each of which bears a code that uniquely identifies each 
product in the group; 

Figure 5C illustrates a flow diagram of a method for tracking a group of gift 
certificates each of which bears a code that uniquely identifies each gift 
2 o certificate in the group; 

Figure 6 illustrates the Response/Request Model in accordance with one 
embodiment of the present invention; 

Figure 7 illustrates a screen print in accordance with one embodiment of the 
security alert warning screen of the present invention; 
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Figure 8 illustrates a screen print in accordance with one embodiment of the test 
certificate of the present invention; 

Figures 9-11 illustrate a particular embodiment of the present invention known 
as the Community Value Network; 

5 Figures 12-23 illustrate screen prints in accordance with one embodiment of the 
reporting system function of the present invention; 

Figures 24 - 25 illustrate screen prints in accordance with one embodiment of the 
merchant manager function of the present invention; 

Figures 26 - 33 illustrate screen prints in accordance with one embodiment of the 
10 promotional campaign management function of the present invention; and, 

Figure 34 illustrates a screen print in accordance with one embodiment of the 
customer care function of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

15 It is to be understood that the figures and descriptions of the present 

invention have been simplified to illustrate elements that are relevant for a clear 
understanding of the present invention, while eliminating, for the purpose of 
clarity, many other elements found in a typical computing-based transaction 
system. Those of ordinary skill in the art will recognize that other elements and/or 

20 steps are desirable and/or required in implementing the present invention. 
However, because such elements and steps are well known in the art, and 
because they do not facilitate a better understanding of the present invention, a 
discussion of such elements and steps is not provided herein. The disclosure 
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herein is directed to all such variations and modifications to such elements and 
methods known to those skilled in the art. 

The system and method of the present invention may provide a highly 
scaleable payment processing service that may integrate and interact with a 
5 seller's web site and transaction processing system, such as to provide account- 
based services, such as credit card processing, consumer-to-consumer payments, 
electronic gift certificates, stored value and micro-payments, digital coupons, order 
fulfillment, and subscription services. The system and method of the present 
invention may enable sellers to offer an innovative range of value creation, 

10 accumulation, tracking, aggregation, redemption, transfer, exchange and trading 
services, using traditional value or currencies as well as web currencies and other 
promotional non-cash value products. The integrated systems and methods of 
the present invention may thereby permit sellers, consumers, and consumer 
account holders to manage on-line and point-of-sale electronic transaction 

15 processing and financial settlement using traditional value, promotional non-cash 
value, and combinations thereof. 

Using the present invention, sellers, financial institutions, and commerce 
service providers may offer customers payment and payment-related transactional 
services. Unlike traditional payment gateways, the present invention provides 

2 0 account-centric services suitable to tie transactional services to customer 

accounts. Additionally, the present invention may provide product modules which 
enhance account relationships with marketing and promotional services. 
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The present invention may be provided as a subscription or member-based 
service to provide value exchange services to businesses that do not themselves 
wish to develop or manage the complexity associated with value-based 
promotions and transaction processing. The invention described herein may meet 
5 the needs of various businesses, including on-line retailers, point-of-sale retailers, 
financial institutions, and portals. The system and method may be implemented 
as a hosted solution or as enterprise software. As further described herein, the 
hosted solution embodiment may provide sellers and businesses with an easy to 
implement gateway, such as XML-based gateway, for example, to interface to a 
10 myriad of payment and payment-related features. The enterprise software 

embodiment offers robust server-side management of a business's interaction 
with a consumer. 

Figure 1 illustrates a block diagram according to an aspect of the present 
invention. As may be seen in Figure 1 , there is shown a transaction processing 

15 and tracking system 10. System 10 may include interconnections and access to 
front-end 15 and back-end 20 services. System 10 may utilize any known 
communications network, including but not limited to networks using the Internet, 
intranet, LAN, WAN, or wireless communication. Front-end services 15 may 
include merchants 50, financial resources 52, service providers 54, and business 

2 0 partners 56. Back-end services 20 may include server and software resources 60 
and consumer accounts 62. 
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Front-end services 15 and back-end services may interface to system 10 
using any communication protocol, including but not limited to Value Exchange 
Markup Language API, Java RMI API, PERL API, or any like language that may 
be apparent to those possessing an ordinary skill in the pertinent arts, for 
5 example. Consumer accounts may include a number of defined purses shown as 
purse 1 64 and purse N 66. Each of front-end services 15 and back-end services 
20 may be interconnected by a gateway 25. Gateway 25, as may be apparent to 
those possessing an ordinary skill in the pertinent arts, may include both hardware 
and software. 

10 Referring now also to Figures 2 and 3, further aspects of gateway 25 are 

shown. In Figure 2, there is shown an exemplary system architecture that may be 
employed to create system 10. Transactions within system 10 may be controlled 
and monitored by gateway 25 and server and software resources 60. 
Transactions may include value based transactions such as sales or purchase. 

15 Transactions may also include shipping of inventory or other type of transaction. 
Also as shown in Figure 2, an exemplary embodiment of a system 10 in 
accordance with the present invention may include security and firewalling, such 
as a cascaded firewall and sun servers, culminating with a dual clustered Sun 
Enterprises Server running software for land sharing and failover. 

2 0 As may be seen in Figure 3, there is shown exemplary software 

architecture that may be employed to create system 10. The software of the 
present invention may provide back-end services including, for example, client 
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management; member account management; merchant account management; 
purse (product and promotion) management; on-line transaction processing and 
messaging; payment authorization (credit card, ACH, E-check); financial system, 
settlement system, and general ledger; and customer care, by way of non-limiting 
5 example only. The software and application of the present invention, in addition to 
authorizing the consumer/member payment, may provide for total financial 
processing, from capture of the data to clearing and settlement, and processing 
for a client's general ledger system. A financial transaction log may be included 
and may provide information to databases on each and every transaction, or 

10 selected transactions, and transactions may be summarized and passed to a 

financial system, such as an Oracle financial system, which settles or awaits the 
financials and funds appropriate parties. The system may include modules for 
financial and accounting services, such as transaction processing suitable for 
managing live financial and non-financial transactions for clients, merchants and 

15 members, financials suitable for performing client settlement and funding, data 

warehousing suitable for dimensioning and processing data and for supporting the 
processing and reporting of financial transactions, transaction logging suitable for 
logging financial and non-financial transaction processed by the system, and 
financial transaction logging suitable for integrating with financials and for 

2 o automating and enhancing the management of financial transactions. 

System 10 may be configured to process 120 transactions per second 
("TPS"), with an average response time of less than one second as measured 
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from the interface to the application tier. Each interconnection may be rated for 
400 TPS (24,000 TPM; 1,440,000 TPH; 34 million TPD), and additional 
interconnections may be added as required. 

Referring now to Figure 4A, there is shown a hierarchy of value creation 
5 and redemption mechanisms. Value creation and redemption may include 

payment or currency, stored values, promotion, subscription, access, substituted 
currency, and/or billing. Value creation and redemption products may provide 
consumer account issuers with the ability to create and issue or install value 
products on a member's or individual's account. Value products may be tracked 

io as financial products in the system and method of the present invention. The 

tracking and crediting/purchasing may be tracked based on groups of products, or 
individual products. Tracking and crediting/purchasing may also be performed on 
any subset of the system, or on the system as a whole. Businesses, including 
warehouses, wholesalers, retailers, and consumers tracking and 

15 crediting/purchasing may be tracked. While any one or more of the mechanisms 
depicted in Figure 4A may be described, for the sake of clarity, a promotional 
system and a gift certificate system will be described as representative examples. 
This promotional system and gift certificate system are representative of the other 
systems and therefore each of the other types will not be described in detail. 

20 Figure 4B is a block diagram illustrating an exemplary promotional system 

100. The promotional system 100 may include a remote station 120, a user 
station 14 communicatively connected 16 to the remote station 12, and a product 
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group 18a, wherein each product 20a, 20b... 20n in the group bears a unique code 
22a, 22b..22n. 

The product group 18a may be a group of products 20a, 20b... 20n sold in a 
retail environment, such as a type of cola, for example. Each product in the group 
5 18a may be substantially identical. The product group 18a may be provided to 
one or more retail outlets by a seller or manufacturer, such as Coke®, for the 
above cola example. Each retail outlet which sells the products 20a, 20b... 20n to 
users 30a, 30b... 30n may be a virtual outlet that sells products using the internet, 
telephone, or mail, or a physical outlet that sells products in a physical store 

10 environment. 

Each product 20a, 20b. ..20n in the group 18a may have a corresponding 
unique code 22a, 22b. ..22n placed thereon. The codes 22a, 22b.. .22n may be 
affixed to the corresponding product by the manufacturer or seller of the product, 
or by the retailer of the product. The codes 22a, 22b... 22n may be numeric, 

15 alphabetic, or alpha-numeric. Each code 22a, 22b... 22n may be, for example, a 
SPIF code or a bar-coded value, and may be printed on the corresponding 
product 20a, 20b... 20n using methods known in the art, or placed under a peel-off 
cover, which, when peeled, reveals the codes 22a, 22b... 22n. Each unique code 
22a, 22b... 22n may be different and separate from any UPC code affixed to the 

20 product 18a. For purposes of the present invention, each code 22a, 22b. ..22n 
may be considered a "new candidate code" before it may be accepted by the 
database server 40 at the remote station 12, as described more fully hereinbelow. 
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As used herein, a new candidate code may be, for example, a unique inventory 
item code. 

The system of the present invention may further track unique codes 
associated with further product groups 18b... 18n. Each further product group 
5 18b... 18n may correspond to an identical group of products, such as soda, 

software, or toys, or services, such as airline tickets, entertainment tickets, or food 
service, sold or marketed by a particular manufacturer or distributor in a 
geographic area. It will be understood by those skilled in the art that each product 
group may be defined to meet the requirements set by each product manufacturer 

10 or distributor using the system. 

The product group 18b may be a group of products 21a, 21b...21n sold in a 
retail environment. Each product in the group 18b may be substantially identical. 
The product group 18a may be provided to at least one retail outlet by a seller or 
manufacturer. Each retail outlet which sells the products 21a, 21 b... 21 n to users 

15 30a, 30b... 30n may be a virtual outlet that sells products using the internet, 
telephone, or mail, or a physical outlet that sells products in a physical store 
environment. 

Each product 21a, 21b...21n in the group 18b may have a corresponding 
unique code 25a, 25b. ..25n placed thereon. The codes 25a, 25b. ..25n may be 
2 o affixed to the corresponding product by the manufacturer or seller of the product, 
or by the retailer of the product. The codes 25a, 25b... 25n may be magnetic, 
numeric, alphabetic, or alpha-numeric. Each code 25a, 25b... 25n may be, for 
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example, a SPIF code or a bar-coded value, and may be printed on the 
corresponding product 21a, 21b.. .21n using methods known in the art, or placed 
under a peel-off cover, which, when peeled, reveals the codes 25a, 25b... 25n. 
Each unique code 25a, 25b. ..25n may be different and separate from any UPC 
5 code affixed to the product 1 8b. For purposes of the present invention, each code 
25a, 25b... 25n may be considered a "new candidate code" before it may be 
accepted by the database server 40 at the remote station 1 2, as described more 

fully hereinbelow. 

The product group 18n may be the last in a series of product groups 
io starting with group 18a. The product group 18n may be a group of products 23a, 
23b... 23n sold in a retail environment. Each product in the group 18n may be 
substantially identical. The product group 18n may be provided to one or more 
retail outlets by a seller or manufacturer. Each retail outlet which sells the 
products 23a, 23b.. .23n to users 30a, 30b.. .30n may be a virtual outlet that sells 
15 products using the internet, telephone, or mail, or a physical outlet that sells 
products in a physical store environment. 

Each product 23a, 23b... 23n in the group 18n may have a corresponding 
unique code 27a, 27b. ..27n placed thereon. The codes 27a, 27b.. .27n may be 
affixed to the corresponding product by the manufacturer or seller of the product, 
20 or by the retailer of the product. The codes 27a, 27b.. .27n may be magnetic, 
numeric, alphabetic, or alpha-numeric. Each code 27a, 27b... 27n may be, for 
example, a SPIF code or a bar-coded value, and may be printed on the 
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corresponding product 23a, 23b... 23n using methods known in the art, or placed 
under a peel-off cover, which, when peeled, reveals the codes 27a, 27b. ..27n. 
Each unique code 27a, 27b... 27n may be different and separate from any UPC 
code affixed to the product 18n. For purposes of the present invention, each code 
27a, 27b... 27n may be considered a "new candidate code" before it may be 
accepted by the database server 40 at the remote station 12, as described more 
fully hereinbelow. 

The user station 14a, 14b. .14n may be a communication device at the 
geographical location of the user 30a, 30b. ..30n. The user station 14 may be, for 
example, a telephone, a personal digital assistant, a personal computer, or a 
network server computer, for example. After purchase of a product 20, 21, 23 
user 30 may then use user station 14 to send the new candidate code 22, 25, 27 
associated with the product 20, 21, 23 to the remote station 12 through a 
communicative connection 16, as discussed hereinbelow. The new candidate 
code 22, 25, 27 may be read or entered into the user station 14 by a code reader 
42 at the user station. The code reader 42 may be, for example, a bar code 
reader, as may be known in the art. The new candidate code 22, 25, 27 may, 
alternatively, be typed into the user station 14 by the user 30. In an embodiment 
wherein the new candidate code 22, 25, 27 may be typed in by the user 30, the 
new candidate code 22, 25, 27 may be typed into a computer interface program 
42, such as an internet browser interface, present on the user station 14. For 
ease of interface, an internet interface may be resident on the remote station 12 in 
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the embodiment wherein an internet browser may be resident on the user station 
14. Alternatively, the new candidate code 22, 25, 27 may be scanned or entered 
at a checkout counter in a retail outlet along with the bar code scan presently 
known in the art. The new candidate code may be associated with the user 30 by, 
5 for example, a frequent customer card, and the identity of the user 30 along with 
code 22, 25, 27 may be sent to remote station 12. 

The remote station 12 may be communicatively coupled 16 to the user 
station 14. This communicative coupling 16 may be, for example, via telephone or 
via internet. The remote station 1 2 may be used to track promotions of the at 

10 least one group 18 of products. The remote station 12 may include a database 44 
and a database server 40. The database 44 may be resident at the remote 
station 12, and, in one embodiment, may be resident on a network at the remote 
station 12. The database 44 may store one of the uniquely identifying codes 22, 
25, 27 upon receipt from user stations 14. Once a code 22, 25, 27 may be stored 

15 in the database 44, it may be a previously received code. 

The database server 42 may be coupled to the database 44. The coupling 
may be generally a communicative electrical connection, such as those known in 
the art. The database server 42 may compare each new candidate code 22, 25, 
27 received from a given user station 14 against the previously received codes 

2 o stored in the database 44. The system may maintain a separate account for each 
user, and each product, and each combination thereof. For example, account 
50aa may be preferably associated with user 30a and product 18b, while 
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accounting 50ab may be associated with user 30a and product 18b, and so on. 
The database server 42 may credit the account 50aa, 50ab, 50ac...50an, 50ba, 
50bb, 50bc...50nn of a user 30 associated with the given user station 14 with a 
non-zero promotional credit only if the new candidate code 22, 25, 27 received 
5 from the given user station 14 was not a previously stored code. The present 
invention may thus prevent fraud by preventing the crediting of a user 30 for 
consumption of a previously consumed product 20, 21, 23. The database server 
42 may then store the new candidate code 22, 25, 27 in the database 44 as a 
previously received code if the new candidate code 22, 25, 27 was not previously 

10 stored in the database 44. In an embodiment, the database 44 may further 
include at least one permissible new candidate code. The permissible new 
candidate codes may be provided by a provider of the products 20, 21 , 23 in the 
group 18, such as the manufacturer, seller, or retailer, and generally encompass 
the codes 22, 25, 27 for all products 20, 21 , 23 in the group 18. The database 

15 server 42 may compare each new candidate code 22, 25, 27 against the at least 
one permissible new candidate code, and the non-zero promotional credit may not 
be credited if the new candidate code 22, 25, 27 doesn't match one of the 
permissible new candidate codes. This may serve as an additional fraud 
protection mechanism. Further, the present invention may include a codification 

2 o scheme for the candidate codes that only the remote station may be capable of 

decoding. Consequently, in an embodiment, fraud may also be detectable due to 
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the use of an improper encoding structure by a user station. Such encoding and 
decoding structures are known in the art. 

In an embodiment, upon receipt of a new candidate code 22, 25, 27 and 
approval of the new candidate code 22, 25, 27 as a permissible candidate code 
and as a previously received code, the database server 42 may store the code 22, 
25, 27 to the database 44 as a consumed code. Once the code 22, 25, 27 
becomes a consumed code, it may not be accepted as a previously received code 
from a subsequent user 30a, and may not be used to credit the account of the 
subsequent user 30a. This consumption may be performed by the present 
invention for products which are capable only of a finite use, such as the cola in 
the above example. 

Also in an embodiment, there are at least two groups 18a, 18b... 18n of 
products 20, 21, 23 and each group 18a, 18b.. 18n may be provided by a different 
provider. In this embodiment, the database server 42 may maintain separate 
previously received codes and separate permissible new candidate codes for 
each provider, and for each different product 20, 21, 23 from the same provider. 
Further, the database server 42 may include one account 50ab associated with 
each user 30a to correspond to at least one product group 18a, and to only one 
product 22a, and the non-zero promotional credit may be credited to that account 
50. In an embodiment, each product 22a may be associated with only one 
provider. 
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The non-zero promotional credits may accumulate in the unique user 
account 50 based on the product or products from a particular provider consumed 
by that user 30. In an embodiment, a credit certificate 60 may be issued to the 
user account 50 once a pre set value of non-zero promotional credits may be 
5 accumulated in the user account 50. This credit certificate 60 may be used, for 
example, as a coupon, rebate, or refund by the user, depending on the particular 
program entertained by the provider. For example, when a sufficient accumulation 
of non-zero credits may be accumulated in a user account 50, that user 30 may 
be notified, for example, by email or telephone, or the provider from whom the 

io consumption has occurred may be notified, that the user 30 has reached a 

threshold. At that point, dependent upon to whom notification was sent, either the 
user 30 may request that the provider provide, or the provider may automatically 
provide, a certificate 60. The certificate 60 may be a gift certificate, partial refund, 
or coupon for future use, for example. 

15 Figure 4C is a block diagram illustrating a gift certificate system 200. The 

gift certificate system 200 may include a remote station 202, a user station 204a, 
204b. ..204n communicatively connected 206 to the remote station 202, and at 
least one gift certificate 208a selected from at least one group 210a of gift 
certificates, wherein each gift certificate 208a in the group 210a bears a unique 

20 code 212a. The group of gift certificates 210a may be that group which may be 
issued by a particular provider. For example, group 210a may include all gift 
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certificates issued by a particular restaurant, a particular department store, a 
particular golf course, or a particular specialty store. 

The gift certificate group 210a may be preferably available for future 
purchase of at least one group of products sold in a retail environment. The gift 
5 certificate 208a, 208b... 208n may be purchased by a third party from the group 
210a of coded gift certificates held by the provider, which third party may give the 
gift certificate 208a, 208b. ..208n to the purchaser. The purchaser may use the gift 
certificate 208a, 208b... 208n to make a purchase in a retail environment. The 
retail environment may be actual or virtual, as discussed hereinabove with respect 

10 to Figure 1 . The retailer may be then a user 220a, 220b... 220n who, through a 
user station 204a, 204b. ..204n at the retail environment, enters in the gift 
certificate code 212a corresponding to the gift certificate 208a, for example, for 
sending to the remote station 202. The provider and the retailer need not be the 
same entity in the present invention. Further, as used herein, all gift certificates 

15 may be held by the provider on an electronic server, and may be delivered to or 
received by the third party or the purchaser in an electronic format only. 

Each gift certificate 208a, 208b.. .208n in the group 210a has a 
corresponding unique code 212a, 212b...212n affixed thereon. The code 212a, 
212b.. .212n may be placed by the maker or seller of the certificate, or by the 

20 provider of the gift certificate 208a, 208b.. .208n. The code 212a, 212b.. .212n 

may be numeric, alphabetic, or alpha-numeric. The code 212a, 212b...212n may 
be, for example, a SPIF code or a bar code, and may be printed on the gift 
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certificate 208a, 208b.. .208n or attached to the gift certificate 208a, 208b.. .208n 
using methods known in the art. Each code 212a, 212b. ..212n may be a "new 
candidate code" 212a, 21 2b... 21 2n before it may be accepted by the database 
server 240 at the remote station 202, as described more fully hereinbelow. 

The system of the present invention may track unique codes associated 
with gift certificate groups 210b. ..210n. Each product group 210b. ..210n 
corresponds to an identical group of gift certificates sold or marketed by a 
particular provider in a geographic area. 

The gift certificate group 210b may be available for future purchase of at 
least one group of products sold in a retail environment. The gift certificate 209a, 
209b. ..209n may be purchased by a third party from the group 210b of coded gift 
certificates held by a provider, which third party then gives the gift certificate 209a, 
209b... 209n to the purchaser. The purchaser then uses the gift certificate 209a, 
209b... 209n to make a purchase in a retail environment. The retail environment 
may be actual or virtual, as discussed hereinabove with respect to Figure 1. The 
retailer may be then a user 220a, 220b.. .220n who, through a user station 204a, 
204b... 204n at the retail environment, enters in the gift certificate code 213a 
corresponding to the gift certificate 209a, for example, for sending to the remote 
station 202. 

Each gift certificate 209a, 209b... 209n in the group 210b has a 
corresponding unique code 213a, 213b.. .213n affixed thereon. The code 213a, 
213b. ..213n may be placed by the maker or seller of the certificate, or by the 
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provider of the gift certificate 209a, 209b. ..209n. The code 213a, 213b.. .213n 
may be numeric, alphabetic, or alpha-numeric. The code 213a, 213b...213n may 
be, for example, a SPIF code or a bar code, and may be printed on the gift 
certificate 209a, 209b. ..209n or attached to the gift certificate 209a, 209b. ..209n 
using methods known in the art. Each code 213a, 213b.. .213n may be a new 
candidate code 213a, 213b...213n before it may be accepted by the database 
server 240 at the remote station 202, as described more fully hereinbelow. 

The gift certificate group 21 On may be the last in a series of gift certificate 
groups starting with group 210a. The gift certificate group 21 On may be available 
for future purchase of at least one group of products sold in a retail environment. 
The gift certificate 211a, 211b...211n may be purchased by a third party from the 
group 21 On of coded gift certificates held by a provider, which third party then 
gives the gift certificate 21 1a, 21 1b... 21 1n to the purchaser. The purchaser may 
then use the gift certificate 211a, 211b...211n to make a purchase in a retail 
environment. The retail environment may be actual or virtual, as discussed 
hereinabove with respect to Figure 1 . The retailer may be then a user 220a, 
220b...220n who, through a user station 204a, 204b. ..204n at the retail 
environment, enters in the gift certificate code 215a corresponding to the gift 
certificate 211a, for example, for sending to the remote station 202. 

Each gift certificate 211a, 211b...211n in the group 210n has a 
corresponding unique code 215a, 215b...215n affixed thereon. The code 215a, 
21 5b.. .21 5n may be placed by the maker or seller of the certificate, or by the 
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provider of the gift certificate 211a, 211b...211n. The code 215a, 215b...215n 
may be numeric, alphabetic, or alpha-numeric. The code 215a, 215b...215n may 
be, for example, a SPIF code, and may be printed on the gift certificate 21 1a, 
21 1b.. .21 1n or attached to the gift certificate 21 1a, 21 1b...21 1 n using methods 
known in the art. Each code 215a, 215b...215n may be a new candidate code 
21 5a, 21 5D...21 5n before it may be accepted by the database server 240 at the 
remote station 202, as described more fully hereinbelow. 

The user station 204a, 204b...204n may be a communication device at the 
geographical location of the user 220a, 220b...220n, which may be the retailer. 
The user station 204a, 204b...204n may be, for example, a telephone, a personal 
computer, or a network server computer. After use of the gift certificate to make a 
purchase, user 220a, 220b...220n may then use his user station 204a, 
204b.. .204n to send the new candidate code 212a, 212b...212n, 213a, 
213b...213n, 215a, 215b...215n to the remote station 202 through a 
communicative connection 206, as discussed hereinbelow. The new candidate 
code 212a, 212b...212n, 213a, 213b...213n, 215a, 215b...215n may be read into 
the user station 204a, 204b...204n by a code reader 222 at the user station 204a, 
204b...204n. The code reader 222 may be, for example, a bar code reader as 
may be known in the art. The new candidate code 212a, 212b...212n, 213a, 
213b...213n, 215a, 215b...215n may, alternatively, be typed into the user station 
204a, 204b...204n by the user 220a, 220b...220n. In an embodiment wherein the 
new candidate code 212a, 212b...212n, 213a, 213b...213n, 215a, 215b...215n 
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may be typed in by the user 220a, 220b.. .220n, the new candidate code 212a, 
212b.. .212n, 213a, 213b.. .213n, 215a, 215b.. .215n may be typed into a computer 
interface program 222, such as an internet browser interface, present on the user 
station 204a, 204b...204n. For ease of interface, an internet interface may also be 
resident on the remote station 202 in the embodiment wherein an internet browser 
may be resident on the user station 204a, 204b.. .204n. 

The remote station 202 may be communicatively coupled 206 to the user 
station 204a, 204b.. .204n. This communicative coupling 206 may be, for 
example, via telephone or via internet. The remote station 202 may be used to 
track the use for purchase of at least one of the group 210a, 210b.. .210n of gift 
certificates 208a, 208b.. .208n. The remote station 202 may include a database 
238 and a database server 240. The database 238 may be resident at the 
remote station 202, and, in one embodiment, may be resident on a network at the 
remote station 202. The database 238 may store one of the gift certificate codes 
212a, 212b.. .212n, 213a, 213b.. .213n, 215a, 215b...215n upon receipt from one 
of the user stations 204a, 204b.. .204n. Once a code 212a, 212b...212n, 213a, 
213b.. .213n, 215a, 215b.. .215n may be stored in the database 238, it may be a 
previously received code. 

The database server 240 may be coupled to the database 238. The 
coupling may be generally a communicative electrical connection, such as those 
known in the art. The database server 240 may compare each new candidate 
code 212a, 212b.. .212n, 213a, 213b.. .213n, 215a, 215b.. .215n received from a 
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given user station 204a, 204b.. .204n against the previously received codes stored 
in the database 238. The database server 240 may then credit an account 250aa, 
250ab...250an, 250ba, 250bb...250bn of a user 220a, 220b.. .220n associated 
with the given user station 204a, 204b.. .204n with a non-zero gift certificate credit 
5 only if the new candidate code 212a, 212b.. .212n, 213a, 213b.. .213n, 215a, 
215b.. .215n received from the given user station 204a, 204b.. .204n was not a 
previously stored code. The database server 240 may then store the new 
candidate code 212a, 212b.. .212n, 213a, 213b...213n, 215a, 215b...215n in the 
database 238 as a previously received code if the new candidate code 212a, 

10 212b.. .212n, 213a, 213b. ..213n, 215a, 215b.. .215n was not previously stored in 
the database 238. In an embodiment, the database 238 may include at least one 
permissible new candidate code. The permissible new candidate codes may be 
provided by, for example, the provider or retailer, and generally encompass the 
codes 212a, 212b.. .212n, 213a, 213b.. .213n, 215a, 215b...215n for all gift 

15 certificates 208a, 208b.. .208n in the group 210a, 210b.. .210n. The database 
server 240 may compare each new candidate code 212a, 212b.. .212n, 213a, 
21 3b... 21 3n, 21 5a, 21 5b... 21 5n against the at least one permissible new 
candidate code, and the non-zero gift certificate credit may be not credited if the 
new candidate code 212a, 212b...212n, 213a, 213b.. .213n, 215a, 215b.. .215n 

20 doesn't match one of the permissible new candidate codes. 

In an embodiment of the present invention, upon receipt of a new candidate 
code 212a, 212b.. .212n, 213a, 213b...213n, 215a, 215b.. .215n and approval of 
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the new candidate code 212a, 212b.. .212n, 213a, 213b.. .213n, 215a, 215b.. .215n 
as a permissible candidate code and as a previously received code, the database 
server 240 may store the code 212a, 212b.. .212n, 213a, 213b...213n, 215a, 
215b...215n to the database 238 as a consumed code. Once the code becomes 
5 a consumed code, it may not be accepted as a previously received code from a 
subsequent user, and may not be used to credit the account 250ca of the 
subsequent user. This consumption may be performed by the present invention 
for gift certificates because gift certificates are inherently capable only of a finite 
use. 

10 Also in an embodiment, there are at least two groups 210a, 21 Ob. ..21 On of 

gift certificates 208a, 208b.. .208n, and each group 210a, 210b.. .210n may be 
provided by a different provider. In this embodiment, the database server 240 
may maintain separate previously received codes and separate permissible new 
candidate codes for each provider, and for each different group 210a, 210b. ..210n 

15 from the same provider. Further, the database server 240 may include one 

account 250ab associated with each user 220a to correspond to at least one gift 
certificate group 210b, and, preferably, to only one gift certificate 208a, and the 
non-zero gift certificate credit may be credited to that account 250ab. Preferably, 
the system may maintain a separate account for each user, and each gift 

20 certificate, and each combination thereof. For example, account 250aa may be 
preferably associated with user 220aa and gift certificate group 210a, while 
account 250ab may be associated with user 220a and group 210b, and so on. In 
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an embodiment, each gift certificate 208 may be associated with only one 
provider. 

The non-zero gift certificate credits may accumulate in the unique user 
account 250, and represent a value equivalent to the purchase value by the third 
party from the provider. In an embodiment, a credit certificate may be issued to 
the user account 250 once a preset value of non-zero gift certificate credits may 
be accumulated in the user account 250. This credit certificate may be redeemed, 
for example, in exchange for cash value or as a credit toward future services. The 
credit certificate may be paid, in an embodiment, by the remote station 202. The 
remote station 202 may then obtain reimbursement, by methods known in the art, 
from the provider based on the payment received by the provider from the third 
party. 

Referring now to Figure 5A, there is shown product and purse relationships 
according to an aspect of the present invention. A purchase and associated value 
exchange may initiate value exchange according to an aspect of the present 
invention. As described hereinabove, particularly with respect to the promotional 
and gift certificate systems set forth, the purses, such as user account 50 and 
user account 250, for example, of entity within system 10 may be accessed, 
debited, and credited by resources within or associated with system 10, such as 
remote station 202. A consumer request may be processed to identify the 
available value sources or purses, as well as the preferred order of preferences 
for those purses. If no order preference is selected by the consumer, then a 
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default set of preferences may be used. A default set of preferences may include 
preferences pre-selected by the consumer account issuer. Processing may occur 
to determine the merchant or purses available to fill the purchase request and 
analyzed for compatibility such as payment options for example. 
5 The present invention may provide for the exchange of value from one 

purse type to another purse type, as discussed hereinabove. Such value 
exchange functions may be programmatic, or may be dynamic via a rules-based 
system. By way of non-limiting example, the rules used in the present invention 
may allow consumers to convert value exchange products from one form to 

10 another, such as cash to reward points, coupon to cash, points to cash, or cash to 
subscription (such as magazine subscriptions), for example. Additionally, the 
present invention may provide for transfer of value products from one member's 
account to another member's account, and further may enable enrollment of non- 
members that have been sent a value product (i.e. cash, coupon, gift certificates, 

15 and the like). The invention may provide consumers with the ability to send 

money, receive money, refer other consumers for membership, access account 
information and payment services from various access devices, including Web 
browsers and wireless access devices such as personal digital assistants and cell 
phones, and spend cash value directly from the user account at any location 

20 which accepts payment from the consumer's account issuer (such as VISA® or 
MasterCard®). 
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In an embodiment of the present invention, the invention may provide 
member account management services, including account creation, updates, and 
reporting, as well as real-time access to member accounts. Members may access 
and review on-line account statements - including all transaction activity for all 
product/purse types. Additionally, members may set up multiple child accounts 
under one parent account - the parent account controlling the funding of child 
accounts. 

In an embodiment of the present invention, the invention may support 
multiple value purses per individual account. Each purse may support a type of 
value exchange, such as electronic cash, micro-payments, loyalty points, or 
electronic coupons. Multiple purses of the same product type may be managed 
on an individual account (i.e., multiple gift certificates, dozens of coupons, several 
cash purses, etc.). Purse value may be reloaded through another purse (i.e., 
cash, coupon, gift certificate) or through traditional payment transactions such as 
credit card. The flow and interaction of value processing as described 
hereinabove will be described hereinbelow using two exemplary embodiments, 
from which it will be apparent to those of ordinary skill in the art that other 
embodiments may be similarly employed. In particular, promotion tracking and gift 
certificate tracking will be described hereinbelow. 

Figure 5B is a flow diagram illustrating a method 300 for tracking promotion 
of at least one group of products, each of which bears a code that uniquely 
identifies each product in the group. The method 300 may include 
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communicatively coupling 302 a remote station to a user station, providing a 
database 304 at the remote station, storing in the database 306 ones of the 
uniquely identifying codes that have been previously received, comparing 308 
each new candidate code received from a given user station against the 
5 previously received codes stored in the database, crediting 31 0 an account of a 
user associated with the given user station with a non-zero promotional credit only 
if such new candidate code received from the given user station was not 
previously stored in the database, and storing 312 such new candidate code in the 
database as a previously received code if such new candidate code was not 

10 previously stored in the database. The method may also include storing 320 the 
previously received code as a consumed code, and preventing 322 entry of the 
consumed code as a previously received code by a subsequent user. The 
method may also include storing 330 at least one permissible new candidate code 
provided by a provider of the products in the group, and comparing 332 each new 

15 candidate code against the at least one permissible new candidate code. 

Crediting 334 of the non-zero promotional credit if the new candidate code doesn't 
match one of the at least one permissible new candidate codes may be then 
prevented at step 310. 

Figure 5C is a flow diagram illustrating a method 400 for tracking a group of 

20 gift certificates each of which bears a code that uniquely identifies each gift 

certificate in the group. The method 400 may include communicatively coupling 
402 a remote station to a user station, providing a database 404 at the remote 
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station, storing in the database 406 ones of the gift certificate codes that have 
been previously received from one or more user stations, comparing each new 
candidate code 408 received from a given user station against the previously 
received codes stored in the database, crediting an account 410 of a user 
5 associated with the given user station with a non-zero gift certificate credit only if 
such new candidate code received from the given user station was not previously 
stored in the database, and storing 412 such new candidate code in the database 
as a previously received code if such new candidate code was not previously 
stored in the database. The crediting may be performed to a retailer's account, 

10 and the non-zero gift certificate credit may be equivalent to a purchase value for 
the gift certificate by a third party, as discussed hereinabove with respect to Figure 
4C. The method may also include exchanging 420, by the retailer, of at least one 
product of value equivalent to the gift certificate for the gift certificate, prior to the 
comparing 408. The method may also include storing 422 the previously received 

15 code as a consumed code, and preventing 424 entry of the consumed code as a 
previously received code by a subsequent user. The method may also include 
storing at least one permissible new candidate code 426 provided by a provider of 
the gift certificates in the group, and comparing each new candidate code 428 
against the at least one permissible new candidate code. Crediting 430 of the 

2 o non-zero gift certificate credit if the new candidate code doesn't match one of the 
at least one permissible new candidate codes may be then prevented at step 410. 
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In order to facilitate transactions the present invention may provide a 
number of processing modes. These distinct and complementary transaction 
processing modes may be used in conducting value exchange (payment) 
transactions. By way of non-limiting example only, numerous processing modes 
5 may be utilized, such as pass-through, direct, peer-to-peer negotiation, local 
negotiation and stand-in. 

In any processing mode, an account identifier may be provided for all 
processing modes. For example, in the pass-through mode, the account identifier 
may be the card number, checking account number, private label card number, or 

10 other account identifier as required by the consumer account issuer and the 
associated processing network for the transaction type being requested. For 
example, other modes may utilize a consumer account which may be identified 
using one of the access methods stored for the account. These may include, but 
are not limited to account ID, external account ID, card number, username and 

15 password. As further explained herein, account access methods may be defined 
in the transaction request as well-formed authentication blocks, such as within a 
document. 

The pass-through processing mode may be used in instances wherein 
there may be no account on file, or wherein the requestor (seller) does not choose 
20 to use the account on file as a means of identifying the end-user (consumer). 

Pass-through processing may be used for simple and efficient processing of credit 
cards, private label cards, and electronic checks, for example. The pass-through 
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model may use the trusted connection to the peer host system as the only means 
of security. No account-level (payment instrument in this case) authentication 
may be performed, unless specified by the requestor. In these cases, account 
authentication may be conducted using third party fraud services, such as eFalcon 
for credit card, or TeleCheck and Certegy for electronic checks, for example. 

In the direct mode, the requestor may have direct knowledge of the purse 
or financial instrument to be acted on, and may know the name of the purse. The 
requestor may send the purse name, the transaction type, and data relevant to the 
transaction type on the transaction request. The direct mode may be used to 
operate on more than one purse or financial instrument at a time. Multiple direct 
mode requests may be contained in a single transaction request. In an exemplary 
embodiment, each direct mode request in the overall transaction must be fulfilled 
or the entire transaction may be declined. The direct mode may be the most 
efficient of the processing modes. The direct mode also eliminates any 
uncertainty as to which purse or financial instrument will be used for the 
transaction. 

In the peer-to-peer mode, the requestor may either wish to perform the 
purse selection on their server, or have implemented client-side software 
permitting the end user to select which purse(s) or financial instrument(s) is/are to 
be used for the associated transaction or transactions. The peer-to-peer model 
may be complemented by the direct model. Once the requesting peer has 
determined which purse(s) or financial instrument(s) to use for the subsequent 
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transaction, the direct model may be used to perform one or more direct 
adjustments to the selected purse(s) or financial instrument(s). 

In the peer-to-peer mode, the requestor may send a transaction that 
requests a list of purses and financial instruments associated with the end-user's 
account. This list may be qualified or unqualified. A qualified request may include 
a "purse filter" that may include varying levels of specificity. Purses may be 
filtered by purse type and purse instance variables, for example. Examples of 
purse types include coupon, stored value, reward, token, and subscription. 
Examples of purse instance variables include purse name, financial instrument 
type (i.e., Visa®, MasterCard®, Amex®, etc.), purse expiration date, and the like. 
Purse filters preferably include logic elements such that scalar purse attributes 
may be qualified through the filter. 

As an example, to request only non-expired coupons, the following logic 
may be applied: 

<PURSE FILTER> 
<RULE> 

<TYPE=Coupon> 
<STATUS=Active> 

</RULE> 
</PURSE FILTER> 



As another example, the requestor may wish to see any coupons, stored 
value, and credit cards associated with the account. The following logic may be 
employed: 

<PURSE FILTER> 
5 <RULE> 

<TYPE=Coupon> 
<STATUS=Active> 

</RULE> 
<RULE> 

10 <TYPE=Stored Value> 

<STATUS=Active> 
<AMOUNT>$2.00> 

</RULE> 
<RULE> 

15 <TYPE=Credit Card> 

<PRODUCT=Visa> 

</RULE> 
</PURSE FILTER> 
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In one embodiment of the present invention, the corresponding response 
logic document may appear as follows: 

<PURSES> 

<PURSE ID=2314567> 

<TYPE=Coupon> 

<NAME=McDonalds Lunchtime Deal> 

<STATUS=Active> 

<BALANCE=2.00> 

<CURRENCY=USD> 

<EXPIRES=02/01/2001> 

</PURSE> 

<PURSE ID=1234567> 

<TYPE=Stored Value> 
<NAME=Speedpass Cash> 
<STATUS=Active> 
<BALANCE=3.25> 
<CURRENCY=USD> 

</PURSE> 
</PURSES> 



The requestor may interrogate this information and may perform a direct 
mode transaction, as may be appropriate to complete their needs. 

The peer-to-peer mode may be less efficient than the direct mode, but may 
allow for a high-degree of interaction with the end-user through the seller-side 
5 interface. Examples of seller-side interfaces that could benefit from using this 
processing mode include, but are not limited to, point-of-sale ("POS") terminals or 
web browsers. 

In a local negotiation mode, the requestor may send a generalized request 
to the host and may let the host determine, through server-side (local) logic, which 

1 o purse(s) or financial instrument(s) will be used to successfully fulfill the transaction 
request. The local negotiation model assumes that the local logic has been "built 
in" to the purse(s) and/or financial instrument(s). The local model may be 
complemented by logic, such as value chaining logic, as further described herein. 
There may be several features of the local mode. First, the consumer (as 

15 the account holder) may have the ability to set the preference of the order in which 
the purses of that consumer are used to fund a value exchange transaction. 
Purses may include any combination of financial instruments and value-based 
purses, such as stored value, discounts, coupons and points, for example. 
Second, the merchant (client) may define filters that are used to identify which 

20 types of purses (financial instruments and other purse types) are used to fund a 
value exchange transaction. As an example, a merchant may not accept online 
debit cards or coupons at a location, or may accept them but only for a particular 
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type of transaction. Further, the consumer account issuer may define the default 
preference order for consumer accounts for the value chains. This default may be 
used to set the consumer's value chaining preference when the account may be 
initialized. This may be an important feature since many consumers will not 
change order preference. This gives the issuer the ability to influence the initial 
purse (financial instrument) in the value chain, which typically will be the issuer's 
own financial instrument (e.g., credit card). 

Value chaining logic may provide a configurable "value chain" element for 
each account. Value chains may define the order for use of the purse(s) and 
financial instrument(s) associated with the account. Value chains may be pre- 
established at the issuer level, as the default, and may be over-ridden by account- 
level value chains. One value chain may be permitted per account (either using 
the issuer's default value chain or one that may be customized by the account 
holder). A value chain may be composed of multiple elements, wherein each 
element in the value chain may be a combination of purse type and, optionally, the 
purse product type (such as the credit card type, "Visa"). As an example, for a 
credit card, the purse type may be "Credit Card" and the purse's product type may 
be "Visa." 

According to an aspect of the present invention, purse types such as 
coupons, tokens, discounts, and rewards may be defined (chained) by their purse 
type. Financial instruments will preferably be defined using both their purse type 



(Credit Card) and their product type (Visa®, MasterCard®, Amex®, Discover®, 
etc.). 

Value chaining logic may provide the end user (account holder) the 
maximum control over the use of the many forms of value (purses and financial 
instruments) that exist on an account. The account holder may optimize the 
account to use free value (such as coupons, rewards, and discounts) before using 
funded value (such as credit cards and electronic checks). While merchants may 
have some control over which products they will (or can) accept at the point-of- 
sale, they may not have the option to demand a specific payment order. Allowing 
the merchant to control payment order may violate certain association rules, such 
as NACHA (direct debit) and Visa®/MasterCard® association rules. The 
merchant may qualify a local negotiation request by sending a filter of purses and 
financial instruments that may be accepted. In this way, the value chain may be 
pre-filtered to eliminate unacceptable forms of payment, before the value chaining 
process may be executed to fulfill the payment request. 

Another feature of value chaining may be the ability to utilize multiple 
purses to fund a single value exchange transaction (e.g., payment for goods or 
services). As an example, the consumer may have specified that coupons, 
discounts, and rewards be used first, then stored value (cash), then a preferred 
credit card to fund purchases. To continue the example, the consumer has a 
coupon good for $10 on qualifying purchases at the merchant location. The value 
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chaining logic may be able to use the $10 coupon to reduce the purchase amount 
before using the credit card to fund the remaining purchase amount. 

Value chaining may provide the merchant with control of whether more than 
one alternative form of payment may be used within a single value exchange 
5 transaction, beyond the financial instrument. This ensures that the consumer 

may not use a coupon and a discount within a single value exchange transaction if 
so desired. 

In one embodiment of the present invention utilizing the local negotiation 
mode, the value exchange transaction process may include the following steps: 

10 1 . A transaction may be submitted from the merchant or merchant's 

agent (such as the network). The transaction may be requesting a 
payment for goods or services for a particular merchant location. If the 
client of sale (merchant) is not specified on the request, the default client 
for the issuer may be used. Next, the consumer account may be 

15 interrogated for all purses (financial instruments and other types) used as 

the total potential pool of qualifying purses. 

2. The consumer's order preference (value chain specification) may be 
retrieved from the account. If no preference is defined, then the account 
issuer's default order preference may be retrieved and used for this value 
20 exchange transaction. 
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3. The client of sale's (merchant's) purse filter may be retrieved. If 
there is no client of sale specified on this transaction, then the purse filter 
may be retrieved for the default client for the consumer account's issuer. 

4. The consumer's purses may be filtered using the client's purse filter 
rules to eliminate any purses that do not qualify for this value exchange 
transaction. If multiple financial instruments match a single instance in the 
filtering hierarchy, all such instruments may be included, and may be 
included in the order that they are encountered. If there are any financial 
instruments that are not ordered (matched to the debit hierarchy), they may 
be appended to the end of the value chain list after the other instruments, 
in the order that they are encountered. 

At this point in the transaction process, all of the potential purses may have 
been filtered (based on the client's filtering preferences) and ordered (based on 
the consumer's ordering preferences). Next, the value chaining logic may be 
applied to the value exchange (debit) request. The first purse may be inspected 
to determine if it qualifies for the value exchange transaction depending on the 
specific rules and data elements contained within the purse. For example, a 
coupon may not qualify if it does not meet certain date or minimum purchase 
requirements. If the purse does apply, it may be redeemed for the qualifying 
purchase. 



If the purse fulfills the entire amount on the value exchange request, then 
the transaction may be completed. However, if the purse only meets a partial 
amount of the value exchange request, then the next purse in the value chain may 
be retrieved and the process may be repeated until the entire value exchange 
5 request amount is fulfilled. In the case where purses in the value exchange 

request were inspected, and potentially used, and the entire amount in the value 
exchange request has not been fulfilled, then the transaction may be ended and a 
"declined" response may be returned to the transaction originator. 

Stand-in processing mode may be activated when the payment processing 

10 system has reached its maximum computing capacity. This capacity may be a 
mixture of capacity thresholds present within each software, hardware, and 
network component in the system. For example, a system client (such as a 
consumer account issuer) may contract for a certain peak processing volume. 
Because system capacity may be shared with other clients, any individual client 

15 (merchant or seller) who exceeds a contracted volume may impact system 
processing for other clients. 

In the stand-in processing (STIP) mode, the transaction processing host 
system may be either unable to respond to the transaction request, or may be 
doing so in a diminished capacity. The purpose of STIP may be two-fold: 1) to 

2 0 provide a high level of authorizations when the host system may be unavailable; 
and 2) to provide an orderly "relief-valve" for periods of high transactions volumes, 



- 43 - 



wherein a portion of transactions may be more efficiently authorized using stand-in 
logic. 

A stand-in authorization, which is an authorization on behalf of the issuer, 
may occur when the issuer may be unable to respond, or when the issuer 
5 delegates authorizations to a third-party processing system at its own risk 
(whether by dynamic stand-in authorization or by permanent stand-in 
authorization). Stand in processing may include the performance of authorization 
by a pre-determined processing system on behalf of the issuer. Similarly, 
alternate limits may include the authorization parameters being set by the issuer 
10 for the alternate processing system in case the primary processing system may be 
unable to respond (cf. alternate parameters, back-up parameters, down option 
limits, down option parameters, dynamic stand-in limits, dynamic stand-in 
parameters). 

In an embodiment of the present invention, STIP may be distributed, in that 
15 each front-end processor may be able to act independently from other front-end 
processors, and from a central data repository. This configuration may be true for 
both information required for stand-in logic, for account or transaction data, and 
for outputs from the stand-in processing. As capacity may be reached, the STIP 
may begin to decline low priority transactions and STIP may next begin to decline 
20 low priority/low utilization transaction types. 

Complete STIP may occur in cases where database may be off-line. 
During normal operations, online transactions may be committed and the results 
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may be written to the queue. One or more data warehouse subscribers may read 
messages from this queue and update the data warehouse tables. The latency in 
this process may run from a few seconds to a few minutes under normal operating 
conditions. The server may read messages from the queue to update relevant 
5 data in the STIP database. This may be the only source of data used to provide 
updates to the STIP database. To switch to STIP mode, the systems operator 
may change the system state to "stand-in", thereby causing the system state 
variable for "stand-in" operating mode to be published to the application servers 
and STIP servers, the application servers to switch to stand-in mode, the 

10 application servers to stop writing transactions to the queue, the application 
servers to begin writing transactions to the queue, the data warehouse 
subscribers (and other subscribers) to have the opportunity to process all 
messages in the queue, and the use of logic may to conduct transactions until the 
system is switched back to normal operating mode. 

15 While in STIP mode, updates may not be written to the database, since the 

only source of updates may be the queue. While in STIP mode, some 
transactions thus may not be fully supported. It may be the responsibility of each 
service to implement its own STIP logic. Many service methods may simply 
decide to decline the transaction request, while some service methods may 

20 provide partial support for a request. 

To switch from STIP back to normal operating mode, the systems operator 
may change the system state to "normal". Setting back to normal mode may set 
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the data warehouse subscribers (and other subscribers) back on-line, may set the 
system state variable for "normal" operating mode to published to the application 
servers and STIP servers, may set the application servers to switch to normal 
mode, may set the application servers to stop writing transactions to the queue, 
5 may set the application servers to begin writing all transactions to the queue, and 
may set the application servers to begin reading transactions from the queue to 
replay the transactions to the system. 

In an embodiment of the present invention, the STIP may be activated by 
analyzing the customer's risk score, the transaction amount, or some other 

10 variable, such as the number of transactions allowed in a day, for example. The 
logic may proceed as follows: customer's risk score > risk score limit, then decline 
the transaction; transaction amount > amount limit, then decline the transaction, or 
the number of transactions allowed per day for an account has been exceeded, 
then decline the transaction. 

15 Interface with the system of the present invention may be facilitated using 

software, such as the Value Exchange Markup Language (VEXML™), for 
example. This software may be included within gateway 25, or may be separate 
therefrom. A systematic protocol may be utilized and certain data formats set to 
interface with the system of the present invention. Further, this protocol may 

20 contain information of import for subscribers to implement some or all of the 
supported transactions from either the client or the server system perspective. 
The software may be designed to provide a simple protocol, such a XML-based, 
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between entities engaged in payment and value exchange transactions, such as 
over the Internet. Various attributes may be targeted in the design, such as ease 
of integration and implementation, for example. 

The interface may be a web server designed to handle a HTTP request, for 
5 example. The interface may also require components to handle the requests and 
update the data stores. The interface may be hardware independent. The 
interface may require requests be made as XML documents and that the 
documents adhere to the naming conventions expected. The communications 
protocol for the present invention may be HTTP and may necessitate a client 

10 make an HTTP post request to a well-known IP address. Further, the application 
level protocol may be XML. HTTP requests may be XML documents. HTTP 
responses may also be XML documents. The communication strategy may be 
HTTP request and response, and the system of the present invention may be 
implemented to provide a response indicating success or failure of the HTTP 

15 request. Transactions may thus take place using this request/response model. 
This model allows for simplicity in implementation from the client/requestor 
perspective because the operations required are strictly described. Figure 6 
illustrates the protocol steps involved in an embodiment of the request/response 
model as form of interaction between A and B. 

20 The request/response model transaction may, in an exemplary 

embodiment, contain the following steps: 
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A initiates a connection, such as a HTTP/1 .x connection, with B on a 
predetermined URL that represents B's address. 

A uses the connection to send the message, such as a VEXML™ 
message, as a POST operation. 

5 A waits for a response to the message to return in the stream. 

B has a server that dispatches the request to the resource specified 
by the URL used in Step 1 . 

B's resource identified in Step 4 reads the message and maps the 
request to the appropriate handler for that request. 

10 B's handler for the request performs the work that the request 

specifies and formats a message as a response. 

B sends the response to A through the connection established in 
Step 1. 

A reads the response and returns it to the process that initiated the 
15 request. 

The above process may be then repeated for further request/response 

cycles. 

In order to facilitate the processing identified above, a message, such as a 
VEXML™ message, may be divided into two distinct parts carried in the parent 
20 envelope element. These parts may be identified as a login and request/response 
data. The login may contain authentication information and addressing necessary 
to validate the user and properly transfer the message to the appropriate location. 
The request/response may contain a specific request, the information to be 
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passed, and the data that may be expected as the response. The following 
example shows the document structure for a request: 



<VEXML> 
<Login> 

5 Login specific information here . . . 

</Login> 
<Request> 

Request specific information here... 
</Request> 
10 </VEXML> 

The following shows an example of the document structure for a response: 

<VEXML> 
<Response> 

15 Response specific information here. . . 

</Response> 
</VEXML> 

As may be seen above, the response structure need not contain a login 
20 element because the response may travel in the same path, such as a HTTP 
request, that the request traveled. 

According to an aspect of the present invention an envelope, such as the 
VEXML™ envelope, may be the root of the message structure, containing the 
other elements. The following example shows a fully specified VEXML™ element. 

2 5 <VEXMLversion="1.0" 

payloadlD="1234567.4567.5678@test.iloyalty.net" 
timestamp= ,, 20003031T1839090800"> 
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A VEXML element contains the following attributes: 



Attribute 


Definition 


Version 


Specifies the version of the VEXML protocol. 


PayloadID 


A unique number with respect to space and time, used 
for logging purposes to identify messages that might 
have been lost or had problems. 
The recommended implementation is: 
datetime. process id. random number(5)hostname 


Timestamp 


The date and time the message was sent, in ISO 8601 
format. (yyyyMMddThhmmssSS i.e. 
2000021 5T1 8300000) 



The login block may contain information which may be used to authenticate 
5 the source of the message. The same login element may be used regardless of 
which specific request may be contained in the body of the VEXML™ message. 
The following example shows a login element: 



<Login> 

10 <lssuer> 

<lssuerName>lssuer</lssuerName> 
<User> 

<UserName>lssuerUserName</UserName> 
<Pswd>lssuerPassword</Pswd> 
15 </User> 

<Client> 

<ClientName>Client</ClientName> 
<User> 

2 o <UserName>lssuerUserName</UserName> 

<Pswd>lssuerPassword</Pswd> 
</User> 
</Client> 
</lssuer> 
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</Login> 



The above example shows the user element under both the client and 
5 issuer elements. It should be noted that the user element need only be included 
in one or the other and not necessarily both elements. If the user element is 
included at the issuer level, the request may be allowed to update any information 
associated with that issuer. If the user element is included at the client level, the 
request may be allowed to update information associated with that client. If the 
10 user element is included at both levels, the issuer user information may be used. 

The login element may be required only once with each envelope. Multiple 
requests may then be sent in each envelope. If authentication has been done at 
the issuer level, the request element may allow for a client element, which will 
override the client element in the login node. In this case, the client element may 
15 be optional on the login node. 

Requests may be sent by clients to request operations. Multiple requests 
may be acceptable. Though the request element may contain virtually any type of 
data, including XML data, the requests may be defined in a specific language, 
such as defined in VEXML™, to be examined. 

20 The subscription API may use a request/response model protocol over 

HTTP. Clients connecting to the hosted services may be provided with a URL for 
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the posting of requests. Transactions may take place using the request/response 
model described above. This model thus allows for simplicity in implementation 
from the client/requestor perspective because the operations required may be 
strictly described, as discussed hereinabove. 

Connecting to the system of the present invention may be accomplished by 
obtaining a server certificate. The server certificate used on the system's testing 
web servers may be self-issued and self-signed, and may not be trusted by default 
clients and browsers. Warnings, such as the one illustrated in Figure 7, may be 
presented when visiting the site programmatically, or manually via a web browser. 
The following instructions are representative, and apply to inventor-issued and 
signed certificates which may be accessed from Internet Explorer: 

From the client used to initiate your testing, browse to https://64-9.51.14/ . 
Select View Certificate. 
Select Install Certificate. 
Select Next. 

Ensure that "Automatically select the certificate store based on the type of 
certificate" has been selected. 

Select Next. 

Ensure that "Trusted Root CA" has been chosen as the store by Internet 
Explorer. 

Select Finish. 
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When prompted, "Do you want to ADD...", select Yes. 
A Dialog box will say, "The import was successful." 
Select OK. 

Next, from Tools, Internet Options, Content, Certificates, under the "Trusted 
5 Root Certificate Authorities" tab will appear on the test certificate, as 

illustrated in Figure 8. Follow up https:// POSTS from this client machine 
to any directory off of this Web server (either via browsing or 
programmatically) will no longer present the warning dialog box. 



10 In order to promote a more complete understanding of the invention, the 

following description of a specific exemplary embodiment of the system and 
method of the present invention is herein provided. The exemplary site may be an 
embodiment for on-line communities. Using this embodiment, stored value and 
digital promotion infrastructure may be provided directly to on-line communities, to 

15 on-line community builders, and to community infrastructure providers. The 

exemplary site product suite may provide basic infrastructure needed to define 
and operate one or more value systems for an individual community, including 
value bank, transaction, and exchange services. Further the suite may provide 
individual communities with the ability to subscribe to a community network, and to 

20 exchange shared value systems with other communities within the network, and 
may provide individual communities, or community networks, the ability to 
exchange non-shared value with other communities or community networks and 
external value systems (e.g., credit card payments, private-label retail loyalty 
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systems, and digital currency providers). These component services may be 
managed by the community manager, by the community infrastructure provider, or 
by the exemplary site as a managed service. 

The community value system of the exemplary site may thus provide basic 
infrastructure needed to define and operate one or more value systems for an 
individual community, including, but not limited to, a set of configurable value 
products used to create the basic value systems used by the community. Further, 
community transactions may provide transaction level support for exchange of 
value among the community, community businesses, and community members. 
The community value bank may provide basic services to support member 
account management, merchant account management, and financial 
reconciliation and settlement. Access to these services may be provided through 
a secure web-based interface to the exemplary site. 

The community may be based on a shared value system which may be 
point-based or based on virtual or real currency. The value system may be 
defined by the community manager by selecting from one of the configurable 
value products. The value system may provide the community, community 
businesses, and community members with a common medium and method of 
exchange. A community may support more than one value system (e.g., loyalty 
points, promotions and cash). Community members may be automatically 
enabled for each community defined value system and thereby allowed to 
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participate in value exchange transactions using one of the available value 
exchange products, including, but not limited to, stored value, sweepstakes, gift 
certificates, coupons and discounts. Additionally, custom value exchange 
products may be created for communities. These products may be made 
available exclusively to the defining community, or may be made available to all 
communities. 

The exemplary site embodiment of the present invention may provide 
sellers with the infrastructure to support traditional value exchange transactions, 
including, but not limited to, consumer to consumer transactions, and business to 
consumer transactions. Consumer to consumer transactions may be transactions 
in which individual community members transact directly with other community 
members, to exchange value. These transactions may be intended to provide the 
virtual equivalence and convenience of cash and check transactions, as well as 
barter. Business to consumer transactions may be transactions in which 
businesses within the community transact directly with community members. For 
example, a business may be created and distribute a coupon that provides 
community members with a 100-point discount towards any purchase from the 
business. 

Other types of transactions may also be available and provided for, such as 
community to consumer transactions, and business to community transactions. 
Community to consumer transactions may allow the community managers to 
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transact directly with the members or consumers, as a non-merchant. Business to 
community transactions may facilitate community businesses transactions with 
consumers through the community, rather than directly with the consumer. This 
form of transaction may use a publish-subscribe model, whereby the business 
may publish an offer to the community or a targeted audience of the community, 
and community members who are subscribers may receive and act on the 
business's published offers. A community value network may be created when 
two or more on-line communities elect to share a value system. Networks, 
therefore, may be an aggregation of communities. Reference may be made to 
Figures 9 and 10, which illustrate two working embodiments of community value 
networks. In Figure 9, there is shown a community value network with a single 
shared value system. In Figure 10, there is shown a community value network 
with multiple share value. 

The community value exchange may enable the exchange of value among 
a community, community value network, and external value systems. Reference 
may be made to Figure 1 1 , which illustrates a community value exchange and its 
relationship to the community value system, the community value network, credit 
card issuers, retail partners, and digital currency partners. 

Referring now to Figures 12-23, there are shown screen prints in 
accordance with one embodiment of the reporting system function of the present 
invention. Referring particularly to Figure 12, there is shown a screen shot of the 
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entrance to web-based reporting functions. As is highlighted in Figure 12, there 
may be a log-on feature associated with report generation and retrieval. After 
utilizing the screen depicted in Figure 12, the entrance way, in the form of a log-on 
screen, is illustratively shown as Figure 13. As may be seen in Figure 13, a APS 
name, user name, password, and authentication may be entered to access the 
system. As may be seen in Figure 14, there is shown a screen shot of the variety 
of reports that may be viewed according to an aspect of the present invention. As 
may be seen in Figure 14, accounting reports, customer to customer, client 
merchant, risk management, and sales financial reports may generated. As may 
be seen in Figure 15, account balances may be viewed and may provide data for 
a report. Reports may also be generated based on a schedule, as is shown in 
Figure 16. For example, reports may be generated based on a one time 
generation, hourly, daily , or weekly, by way of non-limiting example only. 

Referring now to Figure 17, there is shown a feature for viewing and 
retrieving historical reports. As may be seen in Figure 17, reports may be 
generated and the parameters for generation may be seen in the screen shot. 
Additionally, alerts may be created for certain parameters within the system of 
Figure 1. As may be seen in Figure 18, there is shown a screen shot itemizing 
two such alerts. In particular, merchants not meeting the minimum volume may 
cause an alert, for example. Further, reports may be generated to highlight 
regions from which users or purchasers may be located, such as from the United 
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States, or world, for example. As is shown in Figure 19, a depiction of dollar 
figures may be based on regions of the United States, using states as the 
delimitating value. Authorizations may also be viewed, as is shown in Figure 20, 
for specific locations, such as a city, for example. 

Referring now to Figure 21 , there is shown a screen shot of an account 
balance distribution according to an aspect of the present invention. As may be 
seen in Figure 21, account balances may be reported based on identified 
parameters, such as issuer and date. Such an account balance may be identified 
based on promotional purse, reloadable purse, payouts, issuer, and cash, for 
example. As may be seen on Figure 22, transaction detail reports may also be 
created. Such a report may include selecting a date range and enumerating the 
amount and reward associated with a given transaction. A daily financial report 
may also be generated, as illustrated in Figure 23. A daily financial summary may 
be identified based on promotional purse, reloadable purse, payouts, issuer, and 
cash, for example. 

Referring now to Figures 24 - 25, there are shown screen prints in 
accordance with one embodiment of the merchant manager function of the 
present invention. Referring particularly to Figure 24, there is shown a merchant 
chart identifying relationships between and among merchants, as well as 
identifying merchants by type, such as corporation, chain, and franchise, by way 
of non-limiting example only. Referring to Figure 25, there is shown a merchant 
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information screen shot associated with the present invention. As may be seen in 
Figure 25, various features of the merchant may be enumerated and may be 
changed as needed. These features may include merchant parent, merchant 
level, business name, merchant identifier, and merchant currency, by way of non- 
5 limiting example only. 

Referring now to Figures 26 - 33, there are shown screen prints in 
accordance with one embodiment of the promotional campaign management 
function of the present invention. In particular, Figure 26 illustrates a promotion 
campaign management input screen shot. As may be seen in Figure 26, the 
10 particulars of a campaign may be input, such as activation and expiration dates, 
merchant, and type of promotion, by way of non-limiting example only. Merchants 
may be selected, as may be seen in Figure 27. A pull down menu may be 
employed to provide a selection mechanism for merchants of promotions. 
Multiple promotions may be monitored, as may be seen in Figure 28. 

15 Referring now to Figure 29, there is shown a screen shot of a promotion 

modifying screen according to an aspect of the present invention. As may be 
seen in Figure 30, point of sale receipt may be modified according to the current 
promotion. Further, a trigger amount may be modified, as may be seen in Figure 
31 . Referring now to Figure 32, there is shown a screen shot of rewards received 

20 by consumers. Further, in Figure 33, there is shown a reward promotion 
evidencing the requirements for awarding a reward for a promotion. 
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Referring now to Figure 34, there is shown a screen shot in accordance 
with one embodiment of the customer care function of the present invention. As 
may be seen in Figure 34, account information may be displayed in a chart format, 
for example, depicting the date, type of transaction, and the amount of the 
5 transaction for a given consumer within specified starting and ending dates. 

Those of ordinary skill in the art will recognize that many modifications and 
variations of the present invention may be implemented without departing from the 
spirit or scope of the invention. Thus, it is intended that the present invention 
covers the modifications and variations of this invention provided they come within 
10 the scope of the appended claims and their equivalents. 
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